I like this. Recently updated to Alpha 7 to get the pooling functionality only to find that my iOS app wasn't playing nicely with my api anymore. BIGINTs used to be strings only. Why do we need to have two different types going on?

@dresende also, whatever you do decide on doing. The Readme only mentions bigints being typecast to strings.

Just as a side note, I was unsure about the insertId that can be retrieved upon executing an INSERT query.

https://github.com/felixge/node-mysql/blob/master/lib/protocol/packets/OkPacket.js

Apparently in C/C++ bindings mysql treats this field as BIGINT (LONGLONG), whatever the table's original numeric-type field is.
When I was digging node-mysql's source I noticed Parser.prototype.parseLengthCodedNumber checks whether the required number of bits exceeds Number's precision (> 2^53) and returns as string only if so.
I was unsure about whether I should extend the patch to this, but I think the protocol does not allow us to retrieve the "type" of insertId: we just know that it is a length-encoded number that can be up to 64 bits, am I correct in this assumption?

looks like they discussed this in #380 and pulled in the code you mentioned in #382

Looks like @tomasikp is right, closing this for now - but please let me know if I missed something so I can re-open the issue.

@imkira thanks for finding this problem and providing a solution to it as well!

@felixge I think this may have been closed pre-maturely. Although the insertId case has been fleshed out, the main topic of this pull request was the ability to have bigints be returned exclusively as strings.

I tend to agree with @tomasikp, this option might be good for people knowing about bigint problems and wanting to always have these numbers as strings.

#414 Apparently DECIMAL was also changed to the quasi-type (Number/String). I think we should definitely have an option to have all of these remain strings if possible

Like @dresende and @tomasikp said, the point of this commit was not about the insertId but about adding an option for allowing big numbers to be always returned as strings, rather than being a "Number or String"-volatile type. The current behavior is still allowed, and this new behavior is also possible, respectively, by not using or using bigNumberStrings option.
Also, since I screwed up and removed DECIMAL from the list of types that should be handled as big numbers, I am attaching a new pull-request.

#446